home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0126 / 354.txt < prev    next >
Text File  |  1997-04-16  |  27KB  |  616 lines
  1. Info-Atari16 Digest         Wed, 26 Jun 91       Volume 91 : Issue 354
  2.  
  3. Today's Topics:
  4.                      Amiga is better then what???
  5.                   Another Atari write-in campaign...
  6.                  Atari-To-Amiga Convert Info Source!
  7.                     How is Atari doing in Europe?
  8.                      Ian Lepore: e-mail address ?
  9.                      Info-Atari16 Digest V91 #352
  10.                   Problems with Ghostscript (2 msgs)
  11.                            ST and Multisync
  12.                       Sybex STe/TT systems book
  13.                      This week's program (2 msgs)
  14.                       TOS ERROR #35: What is it?
  15.                                Whoops!
  16.  
  17. Welcome to the Info-Atari16 Digest.  The configuration for the automatic
  18. cross-posting to/from Usenet is getting closer, but still getting thrashed
  19. out.  Please send notifications about broken digests or bogus messages
  20. to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU.
  21.  
  22. Please send requests for un/subscription and other administrivia to
  23. Info-Atari16-Request, *NOT* Info-Atari16.  Requests that go to the list
  24. instead of the moderators are likely to be lost or ignored.
  25.  
  26. If you want to unsubscribe, and you're receiving the digest indirectly
  27. from someplace (usually a BITNET host) that redistributes it, please
  28. contact the redistributor, not us.
  29. ----------------------------------------------------------------------
  30.  
  31. Date: 26 Jun 91 04:27:44 GMT
  32. From: esseye!jdbbs!wybbs!therip!FredMail@uunet.uu.net (Rod Fulk)
  33. Subject: Amiga is better then what???
  34. To: Info-Atari16@naucse.cse.nau.edu
  35.  
  36. Tom, Apparently you have not really used an Atari computer...
  37. There are many offerings available on the ST that are not available on any
  38. other computer to date.
  39. Since atari does not make the ST computer any more that I know of you must
  40. compare the capabilities of the STe to that of the amiga.
  41. A 1040 Ste compares VERY favorably to an amiga 500. The ONLY thing the amiga
  42. 500 has over the atari is the fact that the atari can not do as many colors on
  43. the screen at the same time...
  44. However there is a 24bit card available for $800 with a coprocessor of some
  45. sort for really good graphics...
  46. Adding things to the ST come alot cheaper over all then on the amiga and the
  47. standard equipment atari sells is of better quality on average.
  48. Compare....
  49. An Ste with tos 1.6 and blitter performs pretty well...
  50. Compared to an Amiga 500 the amiga only has a slight edge over the Atari..
  51. (Note: for the price no other computer even comes close... )
  52. Compare OS's... The St is built with a much more complete OS then ANY of the
  53. amiga OS's.. (The 2.0 doesnt really count at this point since last time I
  54. looked it was not available on amiga 500's yet)
  55. If you compare the amigas 2.0 to the Mega Ste's 2.x and the TT's 3.X the atari
  56. beats it hands down.
  57. (Beats it in all areas of ease of use and of pure power...) Of course the
  58. amiga does multi task but I have very little use for multi tasking..
  59. (I use a 25 mhz '386 with desqview.. On the BBS multi tasking is nice..)
  60. VERY few people I talk to use multi tasking more then ocassionally.
  61. As to sound? Well The ST is the only one so far that has the capability of 3d
  62. sound. The STe series computers have the capability of using 3 seperate
  63. speakers with different sounds out of each.... 2 of those full 8 bit digital..
  64. It is easy to use HD floppies on an ST.. I have yet to see on on an amiga...
  65. Since the ST uses standard parts it is easy to get most of the items...
  66. Comparing an ST to an Amiga at purely CPU intensive things the Amiga can not
  67. be compared very favorably.
  68. The amiga has a hand up on the serial port since the ST is limited to 19200
  69. baud...
  70.  
  71. ALL the memory can be used in an ST as compared to the amigas limitation of
  72. chip memory... (Note the ST does not waste memory... You must waste memory on
  73. an amiga to do double buffered graphics and digital sound at the same time.)
  74. Each has its own strengths and weaknesses.. The Standard ST is MUCH better
  75. suited to bussiness then an amiga. However the Amiga is better suited to
  76. games and higher resolution color work...
  77.  
  78. Start comparing at the TT to amiga 3000 level and the difference is alot less..
  79. The TT can do some graphic modes the amiga would be jelous of and visa versa.
  80. The sound systems are for the most part the same.. Differences can be over
  81. come by the speed of the processor. If you REALLY push it the amiga can do a
  82. few things better in the graphics arena though.. Over all though you have no
  83. bussiness stating the ST is no where as good as the amiga.. It is not true..
  84.  
  85. However Atari USA is missing the boat....
  86. Actually someone shot the boat they were on while they were sipping a toast
  87. to what they thought was going on... Then federated almost killed them..
  88. From the current trends I would predict that the Atari will come on very strong
  89. in the next five years.. If Atari ever gets over their fatuation of keeping
  90. low graphics to keep the price down and offer a multi tasking environment then
  91. there will be nothing any amigaite can say against the ST... ;-)
  92. (Multi tasking doesnt make a better machine but since most people dont realize
  93. they are not gonna need it they think they need it and might lewt it make some
  94. sort of an effect on them..)
  95.  
  96.  
  97.  * Origin: The R.I.P.  (616)235-2313   [HST] (1:228/24)
  98.  
  99. ------------------------------
  100.  
  101. Date: 26 Jun 91 04:14:48 GMT
  102. From: fernwood!portal!cup.portal.com!Bob_BobR_Retelle@uunet.uu.net
  103. Subject: Another Atari write-in campaign...
  104. To: Info-Atari16@naucse.cse.nau.edu
  105.  
  106. WordPerfect IS succeeding in the US market... in fact, it's one of the
  107. largest software companies in the entire world..!
  108.  
  109. It's Atari Corp which has screwed up the US market, virtually assuring
  110. us that we will NEVER see an upgrade to WordPerfect 4.1 for the ST.
  111.  
  112. WordPerfect can't sell product to non-existant customers with non-existant
  113. computers.
  114.  
  115. What may or may not have happened in Germany isn't going to affect the
  116. US market much, if at all...
  117.  
  118. BobR
  119.  
  120. ------------------------------
  121.  
  122. Date: 25 Jun 91 11:22:01 GMT
  123. From: littlei!intelhf!agora!robart@uunet.uu.net (Robert Barton)
  124. Subject: Atari-To-Amiga Convert Info Source!
  125. To: Info-Atari16@naucse.cse.nau.edu
  126.  
  127. In article <5910@wucc.waseda.ac.jp> ytsuji@wucc.waseda.ac.jp (Y.Tsuji) writes:
  128. >This has been really horrible. Will you please use 'Amiga' word in the
  129. >subject or in the summary so that we can ignore you easily?
  130.  
  131.  
  132.   "Amiga" is in the subject line.  What are you talking about?
  133.  
  134. ------------------------------
  135.  
  136. Date: 26 Jun 91 12:49:00 GMT
  137. From:
  138.  noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia
  139.  .edu!ira.uka.de!fauern!faui43.informatik.uni-erlangen.de!csbrod@arizona.edu
  140.  (Claus Brod)
  141. Subject: How is Atari doing in Europe?
  142. To: Info-Atari16@naucse.cse.nau.edu
  143.  
  144. adamd@rhi.hi.is (Adam David) writes:
  145.  
  146. >From a historical viewpoint, TOS started off as a RAM based OS probably because
  147. >it was still being written. It stabilised into TOS 1.0 the first ROM version.
  148. >Since then we have had infrequent updates usually with only minor changes. A
  149.  few
  150. >bugfixes are made (sometimes in the wrong direction :-() and a few utilities
  151. >added. Suddenly in recent times versions 2.x and 3.x appear with a few more
  152. >bells and whistles. A completely new GDOS is arriving (in RAM of course). TOS
  153. >and GEM almost became fossils in ROM. Some of the material in the ROM should
  154. >(IMHO) rather be made RAM resident so that updates can be made available and
  155. >to give better system flexibility. Manipulation of system-specific hardware
  156. >obviously belongs in ROM but I would like to be able to load GEM when I need
  157. >it, and reclaim its space when I don't.
  158.  
  159. TOS is making its way in just the direction you're pointing at; it is
  160. becoming more modular. MetaDOS essentially replaces GEMDOS. GDOS is
  161. disk-based and allows for external screen drivers. (NVDI is such a
  162. GDOS/screen driver combo.) In fact, TOS is quite modular in itself due
  163. to the hierarchical architecture.
  164.  
  165. If you like, you can work without GEM on your ST today. Just place a
  166. command shell into your AUTO folder. Isn't MiNT meant just for purposes
  167. like these?
  168.  
  169. >>The XBIOS floppy routines worked with HD drives from the day they were
  170. >>created, likewise for BIOS and GEMDOS. Now, isn't that a sign of
  171. >>thoughtful design?
  172.  
  173. >Yes. The low-level stuff for this is all in place, as it should be. Only very
  174. >recent versions have a GEM format option for other than a simple choice
  175. >between single and double sided disks. IMHO the only sensible sector size to
  176. >use on HD disks is 1024 bytes (except for MSDOS compatibility when needed).
  177. >If I understood correctly, only the first and latest versions have been able to
  178. >handle these. In which version number was it fixed?
  179.  
  180. The current TOS versions cannot handle a physical sector size of 1024
  181. bytes. It's not unreasonable to suppose that this won't ever find its
  182. way into TOS again due to compatibility problems. Older TOS versions
  183. won't understand the new format. It isn't even sure that new machines
  184. will have a 1772 built-in that offers such capabilities.
  185.  
  186. As I stated a while ago, I tested a third-party floppy driver some time
  187. ago which offered 1024-bytes-per-sector support. I also haven't given up
  188. the idea of writing a floppy driver on my own. It's not impossible.
  189. The German magazine 'ST-Computer' recently had a full-featured listing
  190. of a replacement for the standard floppy driver allowing for up to
  191. ten disk drives connected to one ST.
  192.  
  193. >Wouldn't it be sensible to have reasonable control over disk format
  194. >built into the desktop?
  195.  
  196. A choice between 9, 10, 18 and 20 sectors per track would be nice, yes.
  197.  
  198. >Shouldn't a decent ramdisk be included in the ROM?
  199.  
  200. Dunno. I don't like the idea very much to include such a beastie into
  201. ROM. I would like to have some more RAM disk support in TOS when it comes
  202. to making memory reset-resident.
  203.  
  204. >A simple text editor would not be out of place in the ROM.
  205.  
  206. I disagree. This would be completely out of place. Except perhaps as
  207. a new GEM object type. (NeXTStep offers things like this.)
  208.  
  209. >It could be worked on in-house as a non-optimised version and then run through
  210. >an optimiser for production. Both speed and space are at a premium even in
  211.  these
  212. >days of multi-megabyte accelerated systems (Whoever thought back then that 4 MB
  213. >wouldn't be enough RAM). Optimisation could be made almost automatic, the only
  214. >handwork necessary would be to mark which parts of the code must not be changed
  215. >because they are in some way critical.
  216.  
  217. The time-critical sections are already written in assembler, especially
  218. the BIOS and the lower screen driver routines. They could and should
  219. be faster, however.
  220.  
  221. >Just eliminating redundant reassignment of variables and making absolute long
  222. >references into absolute short where possible would save enough space to fit
  223. >STE TOS versions into older ST computers without having to move ROMbase to the
  224. >newer (and lower) address.
  225.  
  226. D'accord again.
  227.  
  228. >Enough said for now. This is meant as constructive criticism.
  229.  
  230. And, IMHO, it is!
  231.  
  232. ----------------------------------------------------------------------
  233. Claus Brod, Am Felsenkeller 2,                  Things. Take. Time.
  234. D-8772 Marktheidenfeld, Germany                 (Piet Hein)
  235. csbrod@medusa.informatik.uni-erlangen.de
  236. Claus_Brod@wue.maus.de
  237. ----------------------------------------------------------------------
  238.  
  239. ------------------------------
  240.  
  241. Date: 26 Jun 91 08:00:58 GMT
  242. From:
  243.  lll-winken!elroy.jpl.nasa.gov!sdd.hp.com!uakari.primate.wisc.edu!caen!spool.mu.
  244.  edu!cs.umn.edu!thelake!steve@ames.arpa (Steve Yelvington)
  245. Subject: Ian Lepore: e-mail address ?
  246. To: Info-Atari16@naucse.cse.nau.edu
  247.  
  248. [In article <1991Jun25.111424.27940@newcastle.ac.uk>,
  249.      L.B.Brown@newcastle.ac.uk (L.B. Brown) writes ... ]
  250.  
  251.  > I need to know Ian Lepore's (author of the Gemfast AES and VDI bindings)
  252.  > e-mail address so I can bring to his attention some small bugs I have
  253.  > found. I can't find one in the gemfast V1.5 documentation. Does he have
  254.  > an e-mail address? Does anyone know how to contact him?
  255.  
  256. Ian doesn't seem to have an Internet address, and mail sent to the Citadel
  257. BBS in Denver that he used to call has not been answered.
  258.  
  259. However, Mike Dorman, the person from whom I obtained GEMFAST 1.5, seems
  260. to have a channel to him (perhaps through BIX). If you'll send the report
  261. to me I'll try to have it forwarded to Ian via Mike.
  262.  
  263. (Oh, by the way, I now have the MadMac source code for GEMFAST 1.5, and
  264. I'll mail it off to atari.archive sometime soon.)
  265.  
  266. Here's a note from Ian that was reposted on GEnie.
  267.  
  268. |Category 3,  Topic 23
  269. |Message 13        Mon Jun 24, 1991
  270. |M.DORMAN2 [Mike Dorman]      at 22:24 EDT
  271. |
  272. |The official word from Ian Lepore:
  273. |
  274. | GemFast is one of the few things I'm willing to put a lot of support effort
  275. |into.  If folks want to pass bug descriptions along to me, I'll do my best to
  276. |fix them.  I don't require source code fixes.  GemFast is a strange and
  277. |convoluted critter internally, it'd be unfair of me to ask other folks to wade
  278. |through it and find my bugs.  If they can't give a good description of the
  279. |bug, I'm willing to accept their executable file and a description of how to
  280. |navigate my way in their program to the point where the bug happens.  I have
  281. |good tools for logging what the AES and GemFast are doing internally, so I may
  282. |be in a better position to debug than they are.
  283. |
  284. | The first thing to ask folks when they mention a GemFast bug is: what version
  285. |are you using?  If not v1.5, all bets are off, I *know* there's bugs in
  286. |earlier versions. :-)  I don't guarantee 2-day turnaround on bugfixes or
  287. |anything, but I can often find a workaround real quickly, and if it's a major
  288. |bug, I start thinking about a new release.  (Speaking of which, I've been
  289. |thinking of v1.6 for a while now anyway, I have no bug reports in yet, but I
  290. |do have some outstanding requests for new functions.  Now would be the time
  291. |get those bug reports in...)
  292. |
  293. | In fact, a new GemFast release is the next thing on my to-do list after I
  294. |finish the 'heat-and-serve' release of Sozobon, which ought to be within a
  295. |week or so.  (That's what I said a week ago, however!)
  296.  
  297.  
  298. I don't know what he means by heat-and-serve Sozobon C, but it does sound
  299. interesting, doesn't it?
  300.  
  301.  ----
  302.  Steve Yelvington
  303.  steve@thelake.mn.org
  304.  
  305. ------------------------------
  306.  
  307. Date: Wed, 26 Jun 91 08:16:57 CDT
  308. From: Mike Dorman <MDORMAN1@UA1VM.UA.EDU>
  309. Subject: Info-Atari16 Digest V91 #352
  310. To: Atari List <Info-Atari16@naucse.cse.nau.edu>
  311.  
  312. On Tue, 25 Jun 91 14:30:18 MST Info-Atari16 said:
  313. >Date: 25 Jun 91 11:14:24 GMT
  314. >From: mcsun!ukc!newcastle.ac.uk!turing!n1xxq@uunet.uu.net (L.B. Brown)
  315. >Subject: Ian Lepore: e-mail address ?
  316. >To: Info-Atari16@naucse.cse.nau.edu
  317. >
  318. >Hi,
  319. >
  320. >I need to know Ian Lepore's (author of the Gemfast AES and VDI bindings)
  321. >e-mail address so I can bring to his attention some small bugs I have
  322. >found. I can't find one in the gemfast V1.5 documentation. Does he have
  323. >an e-mail address? Does anyone know how to contact him?
  324.  
  325. You might try sending mail to ianl@bix.com--this might not work, though
  326. and I *do* know that it's not likely to get you a response, since it's
  327. a premium service to send to the Internet from BIX.
  328.  
  329. However, I am sort of responsible, indirectly, for the postings, and
  330. have taken the responsibility to move messages back and forth about
  331. GemFast, so feel free to mail me, with as good a description as you
  332. can manage (or a binary and a description of the problem--Ian says
  333. he could probably track the problems down with a low-level trace
  334. through the binaries).  Ian's in the process of working on another
  335. project (I'm beta testing it), and has a day job, but he's planning
  336. on working on a GemFast upgrade as soon as this other project is out of
  337. the way, so get in those bug reports!
  338.  
  339. Mike.
  340.  
  341. -------------------------------------------------------------------------------
  342. : Michael Alan Dorman   :                                                     :
  343. : MDORMAN1@UA1VM.UA.EDU : Hobbies are things people do when they should be    :
  344. : BIX: syssupport       :   sleeping.  --M.A.D.                               :
  345. : GEnie: M.DORMAN2      :                                                     :
  346. : PostalNet:            :                                                     :
  347. :   Box 8068            : Stonehenge was built by two drunks with no          :
  348. :   Tuscaloosa, AL      :   witnesses.  --P.S.McGhee                          :
  349. :               35486   :                                                     :
  350. -------------------------------------------------------------------------------
  351.  
  352. ------------------------------
  353.  
  354. Date: 26 Jun 91 10:06:46 GMT
  355. From:
  356.  noao!ncar!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!cs.umn.edu!uc!shama
  357.  sh!timbuk!marc@arizona.edu (Marc Bouron)
  358. Subject: Problems with Ghostscript
  359. To: Info-Atari16@naucse.cse.nau.edu
  360.  
  361. In article <1991Jun26.033501.2626@cs.wayne.edu>, pbh@jake.cc.wayne.edu (Patrick
  362.  Haggood) writes:
  363. > I just downloaded ghostscript the other day and have loaded it into
  364. > my E: drive under \ghostscr.ipt directory.  In my cli (MT-C shell) I've
  365. > set GS_LIB to both e:/ghostscr.ipt and e:\ghostscr.ipt in the profile.
  366. > I try to print one of the example files as 'gs chess.ps' and get:
  367. >
  368. > reading ghost.ps (Printing in memory, please ..etc)
  369. > ghost.ps read
  370. > Cant find Fontmap!
  371. > (copyleft info)
  372. > GS<4> (and a prompt)
  373. >
  374. > What am I doing wrong?  What's this fontmap it's looking for?
  375.  
  376. The fontmap file maps between the PostScript font names (e.g. /Times-Roman) and
  377. GhostScript font FILES (e.g. ptmr.gsf).  It live in the ./fonts subdirectory.
  378. Now, to make the rest of it work, you need to modify your GS_LIB variable:
  379.  
  380. GSLIB=e:\ghostscr.ipt\fonts,e:\ghostscr.ipt\ps
  381.  
  382. Basically, it's a search path for any file GS wants to open.  Can't remember if
  383. the slashes face forward or back (forward in the variable, backwards on the
  384. command line?).
  385.  
  386. > --
  387. > Patrick B. Haggood
  388. > Wayne STate University
  389. > Detroit, MI
  390. > Physics - Class of 1991 (-2?)
  391.  
  392. Hope that helps :-)
  393.  
  394. [M][a][r][c]
  395.  
  396.  
  397. ################################################################################
  398. #                           #  marc@sequoia.cray.com           #     .   .     #
  399. #  Marc CR Bouron           #  M.Bouron@cray.co.uk     (ARPA)  #    _|\ /|_    #
  400. #  Cray Research (UK) Ltd.  #  M.Bouron@crayuk.uucp  (DOMAIN)  #   (_|_V_|_)   #
  401. #  +44 344 485971 x2208     #  M.Bouron@uk.co.cray    (JANET)  #     |   |     #
  402. #                           #  ...!ukc!crayuk!M.Bouron (UUCP)  #               #
  403. ################################################################################
  404.  
  405. ------------------------------
  406.  
  407. Date: 26 Jun 91 10:31:20 GMT
  408. From: otter.hpl.hp.com!hpltoad!ghiggins!gjh@hplabs.hp.com (Graham Higgins)
  409. Subject: Problems with Ghostscript
  410. To: Info-Atari16@naucse.cse.nau.edu
  411.  
  412. ++ What am I doing wrong?  What's this fontmap it's looking for?
  413.  
  414. If anyone else sees this error, it's covered in the readme file. The GS_LIB
  415. env-var hold the pathnames to the subdirectories 'ps' and 'fonts' and should be
  416. (in the example) e:/ghostscr.ipt/ps,e:/ghostscr.ipt/fonts.
  417.  
  418. BTW - The postscript generator in the software suite accompanying the Yale
  419. Bright Star catalogue appears to generate valid PS files. Ghostscript
  420. successfully produces prn_1000 files from the PS output. Looks good.
  421.  
  422. Graham
  423. ======
  424.  
  425. ------------------------------------------------------------------
  426. Graham Higgins                  |  gjh%ghiggins@hpl.hp.co.uk
  427. Hewlett-Packard Labs            |  gjh%ghiggins@hplb.hpl.hp.com
  428. Filton Road, Stoke Gifford      |  gjh%hplb.csnet@csnet-relay.arpa
  429. Bristol, U.K.                   |  ...!mcvax!ukc!hplb!gjh
  430. Tel: +44 272 799910 x24014         Fax: +44 272 790554
  431. ------------------------------------------------------------------
  432. Disclaimer: My opinions above are exactly that, mine and opinions.
  433. ------------------------------------------------------------------
  434.  
  435. ------------------------------
  436.  
  437. Date: 26 Jun 91 10:20:56 GMT
  438. From: IFI.UIO.NO!larserio@ucbvax.berkeley.edu (LarsErikOsterud)
  439. Subject: ST and Multisync
  440. To: Info-Atari16@naucse.cse.nau.edu
  441.  
  442. That's right... The monochrome image is small and placed to one side.
  443. The best soulution is a multisync with individual adjustment for EACH
  444. mode on the back panel (my friend has one like that).  Else you have to
  445. adjust HEHT, HORISONTAL and VERTICAL offset all the time :-(
  446.  
  447.  Lars-Erik  /  ABK-BBS +47 2132659  /   ____ ______ ________________________
  448.   Osterud  /  larserio@ifi.uio.no  /   /___    /            The norwegian ST
  449. __________/ ______________________/   ____/   /   Klubben,  user association
  450.  
  451. ------------------------------
  452.  
  453. Date: 26 Jun 91 09:35:50 GMT
  454. From: psuvax1!psuvm!dearn!dmswwu1c!onm07@rutgers.rutgers.edu
  455. Subject: Sybex STe/TT systems book
  456. To: Info-Atari16@naucse.cse.nau.edu
  457.  
  458. In article <13612@uhccux.uhcc.Hawaii.Edu>, kiki@uhunix1.uhcc.Hawaii.Edu (Jack W.
  459. Wine) says:
  460. >
  461. >Has anyone in Germany purchased the new 1500 page Sybex book on the Atari
  462. >STe/TT?  The author is Reschke and the German edition ISBN is 388 745 8885.
  463. >To order, contact:
  464. >
  465.  
  466. Smile. Nobody has it -- yet. It's not finished.
  467.  
  468. >                 Sybex Verlag GmbH
  469. >                 Vogelsanger Weg 111
  470. >                 D-4000 Duesseldorf 30
  471. >                 West Germany
  472. >                 Phone: (49) 211 618020
  473. >                 FAX:   (49) 211 6180227
  474. >
  475. >If you have it, could you please elaborate on the contents?  Also, I would
  476. >like to know the price and if there is any indication that it will be trans-
  477. >lated to English (or your willingness to do so!).
  478. >
  479.  
  480. It contains all information you need about TOS and GEM (well, I HOPE so...),
  481. including all new features up to TOS versions 2.05 and 3.05. The second half
  482. of the book contains lots of technical details about the hardware (again
  483. including the STE/Mega STE and TT hardware; SCC, SCSI and so on).
  484.  
  485. The price will be DM 89.- oder 99.-. And yes, we (the authors) and Sybex
  486. *ARE* interested in translations. Please contact Sybex U.S. or an other
  487. US book company, if you are _really_ interested that this will be done.
  488.  
  489. >Thanks,
  490. >Jack
  491. ___________________________ cut here _____________________________________
  492. Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241
  493. fast eMail: ONM07@DMSWWU1A.BITNET,    slow: jr@ms.maus.de (++49 251 77216)
  494. ____________________ correct me if I'm wrong _____________________________
  495.  
  496. ------------------------------
  497.  
  498. Date: 26 Jun 91 00:49:18 GMT
  499. From:
  500.  noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!hobbes.physics.u
  501.  iowa.edu!maverick.ksu.ksu.edu!kuhub.cc.ukans.edu!wsuiar.wsu.ukans.edu!mwjester@
  502.  arizona.edu (loki)
  503. Subject: This week's program
  504. To: Info-Atari16@naucse.cse.nau.edu
  505.  
  506. In article <BAMMI.91Jun24122520@acae127.cadence.com>,
  507.         bammi@acae127.cadence.com (Jwahar R. Bammi) writes:
  508. > [...]
  509. > Actually, what would be infinitely more useful (to me anyways) would
  510. > be a short technical description of all the neat tricks you guys come
  511. > up with, how you did it etc, and maybe the source.
  512. > --
  513.  
  514. Hear, hear!  Have you considered writing a book on system programming on the
  515. ST?  If you ever do, put me down for a copy.
  516.  
  517. Max
  518.  
  519. mwjester@wsuiar.wsu.ukans.edu
  520. mwjester@twsuvax
  521.  
  522. ------------------------------
  523.  
  524. Date: 25 Jun 91 14:52:58 GMT
  525. From: rlgvax!ccicpg!dorjam!paulm@mimsy.umd.edu (Owner and User)
  526. Subject: This week's program
  527. To: Info-Atari16@naucse.cse.nau.edu
  528.  
  529. In article <2087@uqcspe.cs.uq.oz.au>, warwick@cs.uq.oz.au (Warwick Allison)
  530.  writes:
  531. > >This week's program will copy a file that has a bad sector(s) somewhere in
  532.  the
  533. >
  534. > >100% assembly
  535. >
  536. >
  537. >       ~ Oh.  In that case, I will not use it.
  538.  
  539.   By all means,   PLEASE DON'T!  :~)
  540.  
  541.   I guess I just don't understand that line of thinking......
  542.  
  543.  
  544. --
  545. ---------------------------------------------------------------------
  546.                                 \  Paul Moreau  Orange, California
  547.  UUCP:  ..!ccicpg!dorjam!paulm   \
  548. ---------------------------------------------------------------------
  549.  
  550. ------------------------------
  551.  
  552. Date: 26 Jun 91 04:46:07 GMT
  553. From: fernwood!portal!cup.portal.com!Bob_BobR_Retelle@uunet.uu.net
  554. Subject: TOS ERROR #35: What is it?
  555. To: Info-Atari16@naucse.cse.nau.edu
  556.  
  557. TOS Error 35 generally means the program is corrupted somehow...
  558.  
  559. Your FLASH disk has probably developed a bad sector which renders the
  560. program useless...
  561.  
  562. The best defense against this happening is to back up every disk and only
  563. run programs from the backup disk...  if anything happens to the programs
  564. on that disk, you can always copy the original disk onto a new disk and
  565. use that...
  566.  
  567. BobR
  568.  
  569. (Sorry for not quoting the original message, but my ST has died, and
  570. I'm being forced to use an IBM system with PROCOMM..  about 10% the
  571. functionality of an ST with FLASH...)
  572.  
  573. ------------------------------
  574.  
  575. Date: 26 Jun 91 10:06:39 GMT
  576. From:
  577.  noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!cs.umn.edu!uc!shamash!timb
  578.  uk!marc@arizona.edu (Marc Bouron)
  579. Subject: Whoops!
  580. To: Info-Atari16@naucse.cse.nau.edu
  581.  
  582. In article <1991Jun25.012540.7397@bdt.com>, JONNIE_SANTOS@bdt.COM writes:
  583. > Hello...
  584. >
  585. > I was reading through some of the messages here and saw a phone number
  586. > for the U.K.  (44-344-485971)  Thinking there was a modem at the other I
  587. > called
  588. > with my modem and got a person instead of a squeal.  I wasn't able to
  589. > apologize in voice so I hope you accept my apologies here in print for the
  590. > disturbance.
  591. >
  592. > Regards,
  593. >
  594. > Jonnie Santos
  595. > San Diego, California
  596.  
  597. Apologies accepted :-)   Please email rather than try to connect to our non-
  598. existent modem if there *is* some way I can help you!  BTW, excuse the bandwidth
  599. wastage, but the return email address does not work :-/
  600.  
  601. [M][a][r][c]
  602.  
  603.  
  604. ################################################################################
  605. #                           #  marc@sequoia.cray.com           #     .   .     #
  606. #  Marc CR Bouron           #  M.Bouron@cray.co.uk     (ARPA)  #    _|\ /|_    #
  607. #  Cray Research (UK) Ltd.  #  M.Bouron@crayuk.uucp  (DOMAIN)  #   (_|_V_|_)   #
  608. #  +44 344 485971 x2208     #  M.Bouron@uk.co.cray    (JANET)  #     |   |     #
  609. #                           #  ...!ukc!crayuk!M.Bouron (UUCP)  #               #
  610. ################################################################################
  611.  
  612. ------------------------------
  613.  
  614. End of Info-Atari16 Digest
  615. ******************************
  616.